|
|
|
|
|
|
|
Overview of the Business Rules Subsystem |
|
|
|
|
|
|
|
|
The most complex part of developing any Visual Basic application is the design and implementation of the set of rules that make the application valuable to the user. The general expression for these rules is business rules. Business rule concepts have been floating around the software development and business management world for years. In its three-tier application model, Microsoft describes the middle tier as the business tier. It is this tier that is addressed in this chapter. |
|
|
|
|
|
|
|
|
New Term: Business rules are the policies implemented and enforced in the application that provide measurable value to the user(s) of the application. |
|
|
|
|
|
|
|
|
Nonetheless, don't let the expression business rule throw you off. A more abstract, generic expression is domain rule. I mention this because when some developers read the expression business rule, they automatically associate that with only business applications, and no doubt for good reason. Nonprofit and scientific organizations also use applications for their respective domains, so the expression domain rule is more universal, but not as popular as the expression business rule. |
|
|
|
|
|
|
|
|
A business rule can be as simple as, for example, requiring that a bank customer have a valid account with a positive balance in it in order to make a withdrawal. Or it can be as complex as requiring that a bank customer wanting a revolving line of credit have an existing checking account in good standing, good credit, $250,000 net worth, and income that exceeds $100,000 a year. |
|
|
|
|
|
|
|
|
For nonbusiness applications, business rules translate into domain rules. The same concept applies. An application that tracks the distance of some object must implement the known rule that distance equals rate times time (D=r*t). More complex domain rules are involved in applications that manage space shuttle projects. |
|
|
|
|
|
|
|
|
Because business and domain rules can scale up to be quite complex, object-oriented programming concepts are very effective in comprehending the magnitude of what's involved in enforcing them. For example, recall the bank customer wanting the revolving line of credit. At first glance, it might be tempting for you to simply dive right in and code. However, consider that the revolving line of credit itself might have behavior and attributes that you would discover upon further evaluation. The process of checking for an existing account might involve several tasks not previously known. To calculate the net worth of an individual can be quite involved. The income could be implemented as an attribute if the bank's rule requires taking the customer at his or her word on the loan application, but other banks might require extensive income verification procedures. The bank customer, herself, might exhibit behavior relative to extending a line of credit. Each of these concerns would greatly benefit you by being encapsulated in business classes that enforce business rules. |
|
|
|
|
|